Вы все, конечно же, в курсе, что графические карты уже давно используются не только для просчета графики в играх и требовательных к графике приложениях, но и для вычислительных задач. Сегодня процессоры GPGPU (General Purpose GPU) используются в ИТ-инфраструктурах High Performance Computing (HPC) для решения сложных задач, в том числе машинного обучения (Machine Learning, ML), глубокого обучения (Deep Learning, DL) и искусственного интеллекта (Artificial Intelligence, AI).

Эти задачи, зачастую, хорошо параллелятся, а архитектура GPU (по сравнению с CPU) лучше приспособлена именно для такого рода задач, так как в графических платах сейчас значительно больше вычислительных ядер:

Кроме того, архитектура CPU больше заточена на решение последовательных задач, где параметры рассчитываются друг за другом, а архитектура GPU позволяет независимо просчитывать компоненты задачи на разных процессорных кластерах, после чего сводить итоговый результат.

Вот так, если обобщить, выглядит архитектура CPU - два уровня кэша на базе каждого из ядер и общий L3-кэш для шаринга данных между ядрами:

Число ядер на CPU может достигать 32, каждое из которых работает на частоте до 3.8 ГГц в турбо-режиме.

Графическая карта имеет, как правило, только один уровень кэша на уровне вычислительных модулей, объединенных в мультипроцессоры (Streaming Multiprocessors, SM), которые, в свою очередь, объединяются в процессорные кластеры:

Также в видеокарте есть L2-кэш, который является общим для всех процессорных кластеров. Набор процессорных кластеров, имеющих собственный контроллер памяти и общую память GDDR-5 называется устройство GPU (GPU Device). Как видно, архитектура GPU имеет меньше уровней кэша (вместо транзисторов кэша на плату помещаются вычислительные блоки) и более толерантна к задержкам получения данных из памяти, что делает ее более пригодной к параллельным вычислениям, где задача локализуется на уровне отдельного вычислительного модуля.

Например, если говорить об устройствах NVIDIA, то модель Tesla V100 содержит 80 мультипроцессоров (SM), каждый из которых содержит 64 ядра, что дает в сумме 5120 ядер! Очевидно, что именно такие штуки надо использовать для задач ML/DL/AI.

Платформа VMware vSphere поддерживает технологию vGPU для реализации такого рода задач и возможности использования виртуальными машинами выделенных ВМ модулей GPU. В первую очередь, это все работает для карточек NVIDIA GRID, но и для AMD VMware также сделала поддержку, начиная с Horizon 7 (хотя и далеко не в полном объеме).

Если говорить о задачах машинного обучения, то мы уже писали о результатах тестирования Machine Learning/Deep Learning задач на платформе VMware vSphere. Все это уже сейчас используется в здравоохранении, страховании, финансах и других отраслях.

Еще одна интересная архитектура для решения подобных задач - это технология FlexDirect от компании BitFusion. Она позволяет организовать вычисления таким образом, что хосты ESXi с модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При CUDA-инструкции от клиентских ВМ передаются серверным по сети:

Обмен данными может быть организован как по TCP/IP, так и через интерфейс RDMA, который может быть организован как подключение Infiniband или RoCE (RDMA over Converged Ethernet). О результатах тестирования такого сетевого взаимодействия вы можете почитать тут.

При этом FlexDirect позволяет использовать ресурсы GPU как только одной машине, так и разделять его между несколькими. При этом администратор может выбрать, какой объем Shares выделить каждой из машин, то есть можно приоритизировать использование ресурсов GPU.

Такая архитектура позволяет разделить виртуальную инфраструктуру VMware vSphere на ярусы: кластер GPU, обсчитывающий данные, и кластер исполнения приложений пользователей, которые вводят данные в них и запускают расчеты. Это дает гибкость в обслуживании, управлении и масштабировании.

Более подробно о настройке FlexDirect написано здесь, а документация по продукту доступна тут.

Многие администраторы VMware vSphere сталкиваются с необходимостью развертывания кастомных образов VMware ESXi, например, от HP или Dell, так как они содержат все необходимые драйверы серверного оборудования.

Но процедура, как правило, такова - сначала администратор развертывает последний доступный образ ESXi Custom ISO, а уже после установки накатывает на него обновления через ESXCLI или Update Manager. Это несколько неудобно, так как зачастую требует перезагрузки уже после окончания основной установки.

Если у вас, например, 1500 хостов ESXi, то дополнительное время которое вы потратите за год на процедуры обновления после основной установки может составить до 42 часов в месяц (при условии, что вы накатываете по каким-то причинам образ ESXi на сервер где-то раз в год). Это, конечно же, очень много, поэтому в таких случаях стоит задуматься об интеграции обновлений в кастомизированный образ ESXi.

На самом деле, делается это достаточно просто с помощью PowerCLI в несколько команд (подробно процесс описан в документе Image Builder Patching):

1. Загружаете патчи в формате zip-бандлов и складываете их в одну папку.

2. Добавляете файл образа в software depot:

Add-EsxSoftwareDepot .\update-from-esxi6.5-6.5_update02.zip

3. Получаем имя стандартного профиля образа командой:

Get-EsxImageProfile | fl *

4. Клонируем этот профиль, используя его имя, полученное на предыдущем шаге:

New-EsxImageProfile -CloneProfile “ESX-6.5.0-20180502001-standard” -Name MyCustomImage
-Vendor “Friendly Neighborhood TAM”

Также можно использовать команду выборки профиля по его номеру:

New-EsxImageProfile -CloneProfile (Get-EsxImageProfile |Select -Last 1).Name -Name
MyCustomImage -Vendor “Friendly Neighborhood TAM”

5. Добавляем файл обновления в software depot командой:

Add-EsxSoftwareDepot .\ESXi650-201810001.zip

6. Выводим список профилей ESXi и убеждаемся, что появились оба наших обновленных профиля (см. профили с датой обновления 9/27):

Get-EsxImageProfile

7. С помощью команд Get-EsxSoftwarePackage и (Get-EsxImageProfile MyCustomImage).viblist просматриваем состав пакета и vib-пакетов:

Get-EsxSoftwarePackage

(Get-EsxImageProfile MyCustomImage).viblist

Эта команда покажет только те vib-пакеты, которые были присоединены к кастомному образу:

8. Устанавливаем для текущего профиля самые новые компоненты, которые есть в нашем хранилище:

Set-EsxImageProfile MyCustomImage -SoftwarePackage (Get-EsxSoftwarePackage -Newest)

9. Экспортируем наш текущий обновленный образ в форматы ISO и zip:

Export-EsxImageProfile MyCustomImage -ExportToIso .\ESXi.6.5U2-Patched.iso

Export-EsxImageProfile MyCustomImage -ExportToBundle .\ESXi.6.5U2-Patched.zip

После этого данные файлы можно использовать для развертывания / обновления хостов ESXi.

Если процедура осталась неясна - читайте документ Image Builder Patching.

Очень дельную статью написал Вильям Лам, касающуюся настройки алармов для различных событий в инфраструктуре VMware vSphere. Иногда системному администратору требуется настроить мониторинг каких-либо действий пользователей, которые вызывают генерацию событий в консоли vSphere Client.

Например, вы хотите получать аларм, когда пользователь создает папку (Folder) для виртуального окружения через vSphere Client. Для начала нам понадобится информация, которую мы будем использовать в описании аларма. Для этого мы делаем действие, генерирующее событие, вручную (в данном случае, создаем папку), а после этого идем в раздел Monitor->Tasks, где смотрим описание задачи и связанного с ней события:

Главное здесь для нас - это лейбл "Task: Create folder", по которому мы найдем этот тип событий через PowerCLI, а точнее его Description Id. Открываем консоль PowerCLI и выполняем там вот такую команду, указав лейбл нашего события, найденный в консоли vSphere Client:

$createFolderEvents = Get-VIEvent | where {$_.GetType().Name -eq "TaskEvent" -and $_.FullFormattedMessage -eq "Task: Create folder" }
$createFolderEvents[0].Info.DescriptionId

Результатом будет Description Id нашего события - это Folder.createFolder:

Далее можно создавать аларм, зная Description Id события. Выбираем тип условия Task event, а также описание в виде Description Id, тип условия end with и сам этот ID - Folder.createFolder:

После создания такого аларма, при каждом создании папки он будет срабатывать, что можно увидеть в разделе Triggered Alarms:

Таким же образом вы можете настроить алармы и для любых других событий, происходящих в инфраструктуре VMware vSphere.

В середине января мы писали о первом в этом году обновлении VMware vSphere Client 4.0 - официальном клиенте vSphere на базе технологии HTML5. На днях компания VMware на сайте проекта Labs выпустила новую версию vSphere Client 4.1, которая уже доступна для загрузки.

Давайте посмотрим, что нового появилось в тонком клиенте vSphere версии 4.1:

• Обратно была добавлена поддержка VMware vCenter 6.0, которая пропала в прошлой версии. Теперь в качестве серверов vCenter поддерживаются версии 4.1 - 6.0, 6.5 и 6.7.
• Возможность спрятать виртуальные машины в представлении Hosts and Clusters. Эта фича пришла с десктопных клиентов (Workstation и Fusion), она позволяет убрать ВМ, чтобы они визуально не засоряли консоль (делается это через My preferences -> Inventory).
• Настройки My preferences теперь содержат дополнительные опции, такие как язык, временная зона, параметры консоли и инвентори.
• В Developer Center теперь есть вкладка API Explorer, на которой есть список всех REST API, предоставляемых vSphere SDK.
• Новая компоновка элементов feedback tool. Кроме того, теперь можно можно делать скриншот клиента, даже когда открыты модальные диалоговые окна. Также feedback tool теперь имеет возможности по добавлению скриншотов, что позволяет сравнить фичи между различными версиями клиентов.
• Нотификация об устаревании лицензии теперь показывает 90 дней вместо 60.
• Лицензия Evaluation License теперь отображается в списке лицензий. Сам же список теперь сортируется по дате устаревания лицензий.

Скачать VMware vSphere Client 4.1 можно по этой ссылке.

Одна из новых возможностей, анонсированных в платформе виртуализации VMware vSphere 6.7 - это vSphere Health. О ней мы уже вкратце упоминали вот тут.

Сегодня мы дополним эту информацию. Механизм vSphere Health опирается на глобальную базу знаний VMware, которая позволяет ежедневно выдавать предупреждения о 100 тысячах потенциальных проблем в инфраструктурах заказчиков и решать около 1000 актуальных проблем каждый день.

На данных момент vSphere Health включает в себя около 30 проверок (Heath Checks), которые запускаются для окружения vSphere. Вот примеры проблем, которые могут подсвечивать данные проверки:

• Утечка памяти в драйвере bnx2x
• Хост ESXi, использующий Intel Controller X710 для сетевого адаптера 10GbE SFP+ вываливается в "розовый экран" (PSOD).
• Ошибка L1 Terminal Fault (L1TF – VMM) - уязвимость типа Speculative-Execution в процессорах Intel.
• Хост ESXi 6.5 вываливается в PSOD при отключенном IPV6.

Для фиксирования, аналитики и поиска решений подобных проблем компания VMware использует облако VMware Analytics Cloud (VAC), которое принимает данные телеметрии виртуальных инфраструктур (онпремизных и SaaS-приложений) и формирует рекомендации по решению проблем. Сами данные в обезличенном виде передаются с помощью движка Customer Experience Improvement Program (CEIP).

Облако VAC постоянно анализирует пользовательские виртуальные среды, при этом оно постоянно пополняется новыми знаниями о проблемах, которые в асинхронном режиме отображаются в интерфейсе пользователей в vSphere Client (для vSphere 6.7 и более поздних версий).

Данные инфраструктур заказчиков, которые попадают в облако VAC через механизм CEIP, надежно защищаются. Их использование людьми доступно только для выполнения определенных задач. Сами правила регулируются комитетом Product Analytics Data Governance Board, куда входят инженеры, юристы, специалисты по безопасности и прочие сотрудники с различными ролями. Эта команда регулярно проверяет рабочий процесс использования этих данных. Естественно, эти данные не передаются третьим сторонам.

О том, какие именно данные собираются с помощью CEIP, и как они используются, можно почитать в специальном документе (он небольшой, 10 страниц). Включить CEIP можно через интерфейс vSphere Client следующим образом:

Также этот механизм можно включить при апгрейде платформы vSphere или через интерфейс командной строки (CLI). В рамках CEIP собирается следующая информация о виртуальной среде:

• Configuration Data – как и что у вас настроено в плане продуктов и сервисов VMware.
• Feature Usage Data - как именно вы используете возможности продуктов и сервисов.
• Performance Data - производительность различных объектов виртуальной инфраструктуры в виде метрик и чсиленных значений (отклик интерфейса, детали об API-вызовах и прочее).

Если в рамках вашего плана поддержки вы используете Enhanced Support для CEIP (например, Skyline), то на серверы VMware для анализа отправляются еще и продуктовые логи (Product Logs). Документация по CIEP доступна здесь.

Чтобы посмотреть текущие проверки Health Checks, нужно перейти на вкладку Monitor сервера vCenter Server, после чего перейти в раздел Health:

Там видны проблемы и объекты, к которым они относятся (в данном случае, к хостам ESXi):

Завтра мы расскажем подробнее о том, как работают эти проверки, какие решения они предлагают, и как помогают администратору держать виртуальную инфраструктуру в порядке.

В конце прошлого года мы писали о новых возможностях VMware vCenter в составе обновленной платформы виртуализации VMware vSphere 6.7 Update 1. Среди прочих интересных фичей, vCenter 6.7 U1 получил функцию Health Сhecks, которая позволяет обрабатывать данные телеметрии виртуальной инфраструктуры и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас одна сеть Management network, вам могут порекомендовать ее задублировать.

Вчера мы писали об общем устройстве механизма vSphere Health. Давайте теперь детально посмотрим, как именно это работает. Сделано это чем-то похоже на службы vSAN Health Services, но здесь больше проактивной составляющей (то есть рекомендации генерируются постепенно и еще до возникновения реальных проблем).

Для просмотра основных хэлсчеков сервера vCenter, нужно в vSphere Client пойти на вкладку Monitor и выбрать там раздел Health:

Чтобы эти фичи функционировали корректно, нужно чтобы у вас была включена настройка Customer experience improvement program (CEIP). Если вы не включили ее во время установки vCenter, то вы всегда можете сделать это в разделе Administration клиента vSphere Client:

Надо отметить, что vCenter Health Сhecks не только оповещает о проблемах виртуальной инфраструктуры, но и в некоторых случаях предоставляет ссылки на статьи базы знаний VMware KB, которые могут помочь найти решения.

Если вы нажмете на какой-нибудь из ворнингов, например, "Disk space check for VMware vCenter Server Appliance", то увидите две группы параметров на вкладках "Details" и "Info":

На вкладке Details отображены численные значения и/или объекты виртуальной инфраструктуры, имеющие отношение к предупреждению, а вот вкладка Info разъясняет его суть и дает рекомендации по его устранению. Если же в правом верхнем углу появился значок "Ask VMware", значит для данного предупреждения есть ссылка на статью базы знаний VMware KB, которая может помочь:

Например, здесь на двух из трех хостов ESXi установлена не последняя версия драйвера bnx2x (адаптер Broadcom NetXtreme II 10Gb):

На вкладке Info объясняется, что хосты с такой версией драйвера этого устройства могут вывалиться в "розовый экран":

Если нажмем "Ask VMware", то в новой вкладке откроется статья KB, описывающая проблемы данной версии драйвера и пути их решения:

Если вы сделали изменения конфигурации согласно рекомендациям, вы можете нажать кнопку RETEST в правом верхнем углу, чтобы увидеть только актуальные предупреждения:

Некоторые администраторы инфраструктуры VMware vSphere знают, что существует средство Update Manager Download Service (UMDS), с помощью которого можно скачивать обновления ESXi для последующего их наката со стороны vSphere Update Manager (VUM), интерфейс которого сейчас реализован в vSphere Client на базе HTML5:

UMDS вам может оказаться полезным в двух случаях:

• Вы не можете выставить в интернет сервер vCenter, частью которого является VUM, для загрузки обновлений (например, в соответствии с корпоративными политиками). Поэтому нужно развернуть UMDS на компьютере в DMZ, с которого VUM будет забирать обновления (либо вы будете их перекидывать на VUM вручную).
• У вас есть несколько серверов Update Manager, и вы используете UMDS в качестве централизованной точки распространения обновлений серверов ESXi, чтобы каждый vCenter не скачивал обновления из интернета самостоятельно.

Начиная с Update Manager версии 6.7, сервис UMDS доступен для развертывания на платформах Windows и Linux. Для Windows поддерживаются те же серверные ОС, что и для сервера vCenter, а для Linux список систем можно найти в документации. Вот они:

• Ubuntu 14.0.4
• Ubuntu 18.04
• Red Hat Enterprise Linux 7.4
• Red Hat Enterprise Linux 7.5

Кстати, начиная с vSphere 6.7 Update 1, VMware отменила требование к созданию базы данных для UMDS, поэтому использование сервиса стало еще проще и удобнее.

Если вы используете UMDS на Windows, то вам понадобится Microsoft .NET framework 4.7 и та же версия UMDS, что и сам Update Manager.

На Linux UMDS автоматически не создает переменной PATH для сервиса vmware-umds. Чтобы запустить команду vmware-umds нативно, нужно добавить переменную окружения с путем к сервису следующей командой:

PATH=”$PATH”:/usr/local/vmware-umds/bin

Чтобы на Linux посмотреть текущую конфигурацию UMDS, нужно выполнить команду:

/usr/local/vmware-umds/bin/vmware-umds -G

Здесь мы видим сконфигурированные урлы для хранилищ обновлений (depots), локальный путь к хранению патчей и путь экспорта хранилища, по которому серверы VUM будут забирать обновления. Также здесь мы видим, контент каких версий ESXi нужно скачивать.

Если у вас все хост-серверы одной версии, например, ESXi 6.7, то вы можете отключить скачивание всех остальных образов командой:

sudo ./usr/local/vmware-umds/bin/vmware-umds -S -d embeddedEsx-6.0.0 embeddedEsx-6.5.0 embeddedEsx-6.6.1 embeddedEsx-6.6.2 embeddedEsx-6.6.3

Еще одна важная опция - это задание собственного пути к репозиторию обновлений. Например, если вы используете кастомизированные образы ESXi для серверов Dell, то вы можете добавить адрес репозитория следующей командой:

sudo ./usr/local/vmware-umds/bin/vmware-umds -S --add-url http://vmwaredepot.dell.com/index.xml --url-type HOST

После того, как URL репозитория добавлен, мы можем принудительно скачать все образы обновлений командой:

sudo /usr/local/vmware-umds/bin/vmware-umds -D

Полный список опций UMDS можно получить с помощью вот этой команды:

/usr/local/vmware-umds/bin/vmware-umds --help

Далее вам нужно уже пойти на сервер VMware Update Manager и настроить его на использование с репозиторием UMDS. Если у вас очень высокие требования к безопасности, то вы можете отнести обновления на сервер VUM, например, на флешке. Второй вариант - настроить на UMDS веб-сервер и указать его как путь для обновлений от VUM.

Если вы используете вариант с веб-сервером, то его публичную папку надо настроить на следующий путь по умолчанию:

• C:\ProgramData\VMware\VMware Update Manager\Data\ - на Windows.
• /var/lib/vmware-umds - на Linux.

Некоторые из вас, возможно, слышали об утилите vCheck for Horizon (vCheck-HorizonView), которая позволяет вам на регулярной основе готовить отчеты о текущем состоянии инфраструктуры виртуальных ПК VMware Horizon View. Этот проект базируется на утилите vCheck для VMware vSphere, которая развивается уже почти 7 лет.

В новой версии vCheck for Horizon появились следующие новые возможности:

1. Проверки состояния инфраструктуры ферм RDS:

2. Проверки состояния домена Active Directory:

3. Вызов vCenter API был разделен на 3 части - состояние сервиса vCenter, статус хостов ESXi и состояния подключенных датасторов:

4. Также была добавлена проверка работоспособности механизмов saml и truesso.

Скачать vCheck for Horizon можно по этой ссылке, а пример итогового отчета в формате HTML можно посмотреть вот тут.

Недавно компания VMware объявила о выпуске бета-версии сервиса VMware Automated Virtual Assistant (AVA) - виртуального помощника, который может вам подсобить с поиском документации о продуктах VMware. Этот помощник предоставляется в виде чат-бота, который можно использовать посредством языка естественных запросов NLP (natural language processing). Он агрегирует знания из документации по vSphere, Horizon, vSAN и всем прочим продуктам, а также имеет ответы на соответствующие FAQs, которые есть по практически всем решениям VMware.

Например, вот таким образом можно спросить о документации, касающейся производительности виртуальных процессоров машин (vCPU) на платформе VMware vSphere 6.5:

Для активации помощника VMware AVA нужно просто зайти на сайт VMware Docs и вызвать всплывающее окно с любой страницы.

Пока AVA находится в режиме Training Mode - это означает, что движок еще проходит стадию обучения, и вы можете помочь ему корректно отвечать на вопросы своей обратной связью (для этого предусмотрен соответствующий функционал - например, пометить, какой из предложенных вариантов оказался лучшим). Это позволит объединить похожие запросы и выдавать более релевантные результаты в будущем.

Помимо запросов к документации и часто задаваемым вопросам, вы можете поделиться с AVA своей проблемой (конечно же, касательно виртуальной инфраструктуры:) - и она попытается найти решение.

Кстати, обратите внимание, что на картинке выше показано, что AVA помнит контекст беседы. Она запомнила, что речь будет идти о платформе vSphere версии 6.5, и все дальнейшие вопросы она будет воспринимать как относящиеся именно к этому продукту.

Пока Automated Virtual Assistant доступен только на английском языке, но обещают и поддержку других языков. Однако, как мы знаем, VMware не очень жалует русский, поэтому не стоит ждать его поддержки, по крайней мере, в ближайшем будущем. А так AVA - штука весьма интересная.

На сайте проекта VMware Labs появилась интересная и полезная некоторым администраторам vSphere штука - USB Network Native Driver for ESXi. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

На данный момент драйвер поддерживает 3 самых популярных чипсета на рынке:

• ASIX USB 2.0 gigabit network ASIX88178a
• ASIX USB 3.0 gigabit network ASIX88179
• Realtek USB 3.0 gigabit network RTL8153

А вот, собственно, и сами поддерживаемые адаптеры:

Надо отметить, что это сравнительно недорогие устройства, которые может позволить себе каждый администратор платформы vSphere.

Установка драйвера производится одной командой:

esxcli software vib install -d /path/to/the offline bundle

Затем нужно будет перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0. Но чтобы приаттачить такой NIC к виртуальному коммутатору vSwitch, придется добавить в /etc/rc.local.d/local.sh такой скрипт:

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

  count=0

  while [[ $count -lt 20 && "${vusb0_status}" != "Up" ]] ]

  do

sleep 10

count=$(( $count + 1 ))

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

done

if [ "${vusb0_status}" = "Up" ]; then

  esxcfg-vswitch -L vusb0 vSwitch0

  esxcfg-vswitch -M vusb0 -p "Management Network" vSwitch0

  esxcfg-vswitch -M vusb0 -p "VM Network" vSwitch0

  fi

Драйвер работает с VMware vSphere 6.5 и 6.7. Скачать его можно по этой ссылке.

Больше пяти лет назад мы писали про проект vCenter Server Simulator 2.0 (VCSIM), который позволял протестировать основные интерфейсы VMware vCenter без необходимости его реального развертывания (а значит и без лицензии). Проблема в том, что он был выпущен для VMware vSphere и vCenter версий 5.5 и с тех пор не обновлялся.

Зато есть аналог старому VCSIM - новый проект govcsim, написанный на языке Go (Golang). Он точно так же умеет предоставлять API-ответы на вызовы к vCenter Server и ESXi.

Несмотря на то, что этот симулятор написан на Go, он позволяет вам работать с vCenter посредством любого языка и интерфейса, умеющего общаться через API (в том числе, PowerShell). То есть, вы можете соединиться через PowerCLI к VCSIM Docker Container и работать с ним как с сервером vCenter.

Сам контейнер nimmis/vcsim можно скачать отсюда. Pull-команда для него:

docker pull nimmis/vcsim

Далее можно выполнить вот такой сценарий (взято у Brian Bunke):

docker run --rm -d -p 443:443/tcp nimmis/vcsim:latest

If ($IsMacOS -or $IsLinux) {

$Server = 'localhost'

} Else {

$Server = (Get-NetIPAddress -InterfaceAlias *docker* -AddressFamily IPv4).IPAddress

}
If ($PSVersionTable.PSVersion.Major -ge 6) {

Test-Connection $Server -TCPPort 443

}
Connect-VIServer -Server $Server -Port 443 -User u -Password p

# Did it work?

Get-VM

# Or Get-VMHost, or Get-Datastore, etc.

Этот код делает следующее:

• Запускает docker-контейнер VCSIM локально (если у вас его нет, то он будет загружен).
• На Windows-системе получает IP-адрес адаптера DockerNAT.
• После запуска контейнера тестирует, что порт 443 отвечает.
• Использует модуль VMware.PowerCLI интерфейса PowerShell для соединения с vCenter Simulator.

Симулятор на данный момент поддерживает не все множество API-методов (смотрите документацию). Вот так, например, можно вывести список всех поддерживаемых методов и типов:

$About = Invoke-RestMethod -Uri "https://$($Server):443/about" -Method Get

$About.Methods

$About.Types

Например, вы можете использовать PowerOffVM_Task, PowerOnMultiVM_Task и PowerOnVM_Task. Из PowerCLI попробуйте также протестировать командлеты Stop-VM и Start-VM. Ну а дальше изучайте документацию к библиотеке govmomi.

Во время прошедшего летом прошлого года VMworld 2018 компания VMware представила много интересных новостей на тему будущей функциональности продукта для создания отказоустойчивых хранилищ VMware vSAN. Например, мы писали о технологии Native Data Protection (это часть 1 этого цикла статей), а сегодня поговорим о сервисах хранения.

Диски First Class Disk (FCD)

Для vSAN уже есть поддержка так называемых дисков First Class Disk (FCD), они же называются Improved Virtual Disk (IVDs) или Managed Virtual Disk. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes (он называется vSphere Cloud Provider) для создания постоянных (persistent) томов контейнеров Docker. Этим всем занимается опенсорсный проект Project Hatchway от VMware.

Работать с такими дисками очень неудобно - для них приходится создавать отдельную виртуальную машину к которой цепляется этот диск, а потом, по завершении какого-либо процесса, отсоединяется, и машина уничтожается. Так, например, работает средство для резервного копирования App Volumes Backup Utility, о котором мы писали вот тут. При бэкапе этих дисков создается временная Backup VM:

Второй пример - инфраструктура vSphere Integrated OpenStack (VIO), где для того, чтобы включить хранилище Cinder (OpenStack Block Storage) для потребления дисковой емкости VMDK-файлов, нужно создавать вспомогательные Shadow VM для каждого тома Cinder, к которому цепляется VMDK-диск.

Все это неудобно, поэтому и придумали формат дисков First Class Disk (FCD), которому не требуются временные виртуальные машины и которые реализуют сервисы, необходимые приложениям или другим сервисам. Например, бэкап таких дисков можно делать без создания вспомогательной ВМ.

Информация о дисках FCD хранится в каталоге базы данных vCenter. Она содержит глобальные уникальные идентификаторы UUID и имена дисков. UUID позволяет переместить диск в любое место без конфликтов.

Впервые API для работы с FCD появился в VMware vSphere 6.5, например, вот хороший пост от Вильяма Лама об этом. Но в этом релизе было ограничение на резервное копирование FCD-дисков, которые не присоединены к ВМ (в качестве workaround приходилось все же использовать Dummy VM).

В vSphere 6.7 это ограничение было снято, но остались еще некоторые требования - FCD нужно было восстанавливать с тем же UUID и на тот же датастор, откуда он был взят. Также еще одним ограничением была невозможность API отслеживать блоки, изменившиеся с момента последней резервной копии, то есть невозможность инкрементального резервного копирования (подробнее здесь).

Ну а в vSphere 6.7 Update 1 была анонсирована ограниченная поддержка FCD для vSAN. Пока поддержка предоставляется еще с ограничениями для служб health service и capacity monitoring. Однако при этом пользователи Kubernetes могут использовать диски FCD на хранилищах vSAN для персистентных хранилищ контейнеров, и в то же самое время тома vSAN могут использоваться для виртуальных машин:

Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке.

В следующей статье мы расскажем про Cloud Native Storage (CNS) и vSAN File Services.

Компания StarWind, ведущий производитель решений для создания отказоустойчивых программных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, приглашает на бесплатный вебинар "Building a stretched cluster: Keep your data always secure".

Вебинар пройдет 7 февраля в 22-00 по московскому времени.

На мероприятии Алексей расскажет обо всех нюансах развертывания географически "растянутого" кластера для виртуальных машин в части хранилищ. В рамках вебинара будет рассказано, как построить такой кластер, каким аспектам отказоустойчивости (HA) уделить особое внимание, и какие меры необходимо принять в целях обеспечения безопасности такой среды. Ну и, конечно же, Алексей расскажет о том, как предотвратить ситуацию Split Brain в таких сценариях.

Регистрируйтесь бесплатно!

Недавно компания VMware объявила о выпуске обновленной версии решения VMware PKS 1.3 (Pivotal Container Service), предназначенного для управления гибридными средами Kubernetes в онпремизных и публичных облаках. Напомним, что об анонсах на VMworld Europe 2018, касающихся этого продукта, мы писали вот тут.

Тогда было объявлено о покупке компании Heptio, которую основали создатели Kubernetes. Она предоставляет набор продуктов и профессиональных сервисов для управления контейнерами Kubernetes в онпремизных, публичных и гибридных облачных средах. Помимо управления контейнерами, решения Heptio предоставляют такие сервисы, как оркестрация приложений, поддержка жизненного цикла (развертывание, хэлсчек) и обеспечение доступности (снапшоты, резервное копирование).

Теперь кое-что из этого было добавлено в VMware PKS, который стал поддерживать облачную среду Microsoft Azure. Кроме того, в продукте были улучшены функции контроля сетевого взаимодействия, безопасности и управления.

Давайте посмотрим, что нового появилось в PKS 1.3:

1. Поддержка публичного облака Microsoft Azure.

Ранее PKS поддерживал облачные среды VMware vSphere, Google Cloud Platform и Amazon EC2. Теперь он работает и в Azure:

PKS позволяет самостоятельно развернуть кластеры Kubernetes в облаке (или сразу нескольких облаках) и получить все инструменты для ежедневной эксплуатации решения.

2. Улучшения гибкости и средств настройки сетевой среды и инфраструктуры безопасности.

Теперь сетевые профили кластеров, которые появились еще в версии 1.2, получили еще больше параметров настройки.

• Поддержка нескольких Tier 0 маршрутизаторов для лучшей изоляции контейнерных сред. Один экземпляр VMware NSX-T может обслуживать несколько Tier 0 маршрутизаторов, что дает не только функции безопасности, но и возможности настройки отдельных диапазонов IP для каждого роутера и его клиентов.

• Маршрутизируемые IP-адреса, назначаемые группам узлов (Pods), что позволяет обеспечить их прозрачную коммуникацию с внешним миром (а также достучаться к ним из внешнего мира). Если необходимо, можно использовать и NAT-схему. Более подробно об этом написано здесь.
• Для групп Pods можно перекрыть глобальные настройки диапазона IP-адресов и размера подсети, задав их для отдельных групп. Это дает больше гибкости в плане использования глобального диапазона адресов.
• Поддержка больших (large) балансировщиков в дополнение к small и medium. Это увеличивает число предоставляемых сервисов, число групп на бэкенде в расчете на сервис, а также количество транзакций в секунду на сервис.
• Лучшая изоляция окружений за счет размещения нескольких VMware PKS Control Planes в рамках одного экземпляра NSX-T. Каждый управляющий объект VMware PKS control plane можно разместить на выделенном маршрутизаторе NSX-T Tier 0. Это позволяет лучше разделить окружения и, например, обновлять тестовую среду независимо от производственной, работая с двумя экземплярами PKS.

3. Улучшенные операции управления.

Здесь произошли следующие улучшения:

• Средства резервного копирования и восстановления кластеров Kubernetes. Теперь, помимо бэкапа средств управления Control Planes, появилась возможность бэкапа и stateless-нагрузок в контейнерах средствами тулсета BOSH Backup and Restore (BBR).
• Возможность проведения смоук-тестов. С помощью PKS 1.3 возможно создание специализированной тестовой среды, которую можно использовать для проверки апгрейда кластера, чтобы убедиться, что на производственной среде апгрейд пройдет нормально. После окончания теста тестовый кластер удаляется, после чего можно спокойно апгрейдить продакшен.

4. Поддержка Kubernetes 1.12 и другие возможности.

VMware PKS 1.3 поддерживает все стабильные физи релиза Kubernetes 1.12. Со стороны VMware они прошли тесты Cloud Native Computing Foundation (CNCF) Kubernetes conformance tests.

Также в рамках одной группы контейнеры могут иметь общие тома. Это может пригодиться, например, для общей базы данных нескольких приложений в разных контейнерах.

Кроме того, компоненты NSX-T и другие управляющие элементы, такие как VMware vCenter, можно разместить за HTTP proxy, требующим аутентификации. Ну и VMware PKS 1.3 включает решение Harbor 1.7 с новыми возможностями, такими как управление диаграммами Helm, улучшенная поддержка LDAP, репликация образов и миграции базы данных.

Более подробно о VMware PKS 1.3 написано по этой ссылке. Также больше подробностей об обновлении можно узнать тут, а вот тут можно пройти практическую лабораторную работу по решению PKS.

Компания StarWind Software, известная своим лидирующим решением Virtual SAN для создания отказоустойчивых хранилищ для виртуальных машин VMware vSphere и Microsoft Hyper-V, продолжает выпускать полезные бесплатные утилиты. Например, напомним, что ранее мы писали о StarWind Deduplication Analyzer.

На этот раз StarWind выпустила средства для бенчмаркинга RDMA-соединений между серверными системами, которые используются для прямого доступа к памяти между хостами в рамках кластера.

Для тестирования RDMA-соединений есть различные утилиты, но они разработаны для различных операционных систем, и их трудно сопрягать между собой. Также они показывают либо задержки (latency), либо пропускную способность (bandwidth), а rPerf выводит обе этих метрики. Ну и, конечно же, ее можно использовать для Windows и Linux одновременно.

Давайте посмотрим, как это работает. Для тестирования вам понадобятся системы Windows 7 / Windows Server 2012 или более поздние, а если вы хотите использовать Linux - то CentOS 7 или Ubuntu.

Сетевой адаптер (NIC) должен иметь настроенные механизмы Network Direct Provider v1 и lossless RDMA. Для адаптеров нужны последние версии драйверов, так как стандартный драйвер Windows не поддерживает ND API. Для систем Linux нужны драйвера с поддержкой RDMA и RoCE.

1. Скачиваем утилиту StarWind rPerf по ссылке:

https://www.starwindsoftware.com/starwind-rperf#download

Далее на Linux системе выполняем chmod +x rperf.

2. Выполняем следующую команду для выставления хоста Windows Server в качестве сервера (полный список команд и флагов утилиты приведен вот тут):

nd_rperf.exe -s -a 10.1.2.11

3. Выполняем такую команду для запуска теста производительности соединения из системы Linux (со стороны клиента):

./rperf -c -a 10.1.2.11 -C 100000 -S 4096 -q 16 -o W

Эта команда сгенерирует 100 тысяч операций записи с размером буфера 4096 и глубиной очереди (queue depth) размером 16:

В результатах вывода мы увидим значения throughput и latency (см. скриншот). Также можно сделать и Linux сервером:

./rperf -s -a 10.1.2.12

а Windows - клиентом:

nd_rperf.exe -c -a 10.1.2.12 -C 10000 -S 4096 -q 16 -o R

Скачать утилиту StarWind rPerf можно по этой ссылке.

После апгрейда виртуальной инфраструктуры на версию VMware vSphere 6.7 Update 1, а также при ее регулярном обновлении и эксплуатации, нужно поддерживать актуальные версии VMware Tools в виртуальных машинах.

Для начала напомним, что самую последнюю версию VMware Tools для ваших виртуальных машин всегда можно скачать по этой ссылке:

https://www.vmware.com/go/tools

Чтобы централизованно обновлять VMware для всех ВМ, вам нужно настроить единый репозиторий на всех хостах ESXi, из которого будет происходить апдейт. Сначала нужно создать для этого папку, например:

/vmfs/volumes/vsanDatastore/vmtools

Далее нужно скачать последнюю версию VMware Tools по ссылке выше и положить ее в созданную папку (включая папки "vmtools" и "floppies").

Теперь на каждом хосте ESXi нужно обновить указатель ProductLocker через интерфейс MOB (Managed Object Browser). Для этого надо зайти по ссылке:

https://VCSA_FQDN/mob

И там перейти в:

Content > rootFolder > childEntity > hostFolder > host 

Далее нужно выбрать хост ESXi, для которого вы хотите обновить этот указатель. Здесь есть два API вызова, которые вам понадобятся:

Вызов QueryProductLockerLocation покажет вам текущий указатель на папку с VMware Tools на хосте (ProductLocker):

Метод UpdateProductLockerLocation_Task позволит вам обновить размещение для пакетов VMware Tools для этого хоста, добавив путь к нужной папке в параметр path:

Теперь снова вызовите QueryProductLockerLocation, чтобы увидеть, что путь к папке обновился:

Теперь все остальные хосты ESXi также нужно перенастроить на путь к этой папке, чтобы они брали обновления VMware Tools из единого места, где всегда будет лежать последняя версия пакета.

В мае прошлого года компания VMware выпустила обновление vSphere Integrated Containers 1.4 (VIC), а в июле мы писали про апдейт VIC 1.4.2. В январе этого года VMware выпустила новую версию vSphere Integrated Containers 1.5 - давайте посмотрим, что в ней нового.

1. Квоты хранилищ (Storage Quotas).

Квоты хранилищ позволяют администратору vSphere задавать лимиты хранения, которые доступны объектам Docker Endpoint, с помощью опции --storage-quota для команды vic-machine create. Квоты можно задавать для каждого из объектов Virtual Container Host (VCH), они срабатывают при создании контейнера или загрузке образа. В примере ниже видно, что квота задана на уровне 15 ГБ и при попытке завести еще один контейнер busybox возникает ошибка о превышении квоты по хранилищу.

~$ docker –H :2376 –tls info

vSphere Integrated Containers v1

Backend Engine: RUNNING

VCH storage limit: 15 GiB

VCH storage usage: 9.542 GiB

VCH image storage usage: 1.656 MiB

VCH containers storage usage: 9.451 GiB
~$ docker -H :2376 --tls run --id busybox

  docker: Error response from daemon: Storage quota exceeded. Storage quota: 15GB; image storage usage: 0.002GB, container storage usage: 9.451GB, storage reservations: 9.541GB.

2. Возможность загрузки альтернативного ядра Linux Kernel.

Photon OS дает массу возможностей для загрузки контейнеров, однако некоторым пользователям требуется собственная конфигурация ядра или вообще другой Linux-дистрибутив. Для них сделана возможность загружать собственное ядро, например, ниже приведена команда для запуска ядра CentOS 6.9, в среде которого будут работать контейнеры:

~$ bin/vic-machine-linux create --target 10.161.187.116 --image-store nfs0-1 –user 'administrator@vsphere.local' --bridge-network bridge --public-network management --container-network vm-network --compute-resource cls --no tlsverify --force --name=centos6.9-demo --bootstrap-iso=bin/boostrap-centos-6.9.iso

3. Поддержка VMware NSX-T.

Помимо поддержки решения VMware NSX-V, которая была введена в прошлых версиях, теперь VIC 1.5 поддерживает и решение NSX-T для обеспечения прозрачной коммуникации между контейнерами, с управлением на основе политик и микросегментацией трафика. Делается это с помощью команды vic-machine create –container-network.

Виртуальные машины с контейнерами могут быть подключены к распределенной портгруппе логического коммутатора NSX, что позволяет использовать выделенное соединение этих ВМ к сети:

4. Поддержка Photon OS.

vSphere Integrated Containers 1.5 поставляется со всеми необходимыми компонентами для работы с Photon OS версии 2.0. Этот релиз предоставляет расширенные возможности обеспечения безопасности, а также поддерживает все новые функции второй версии Photon OS.

Получить больше информации о VIC 1.5 можно на этой странице.

На сайте проекта VMware Labs появился апдейт основного средства управления виртуальной инфраструктурой - VMware vSphere Client 4.0. Напомним, что, начиная с версии vSphere 6.7 Update 1, vSphere Client является официально поддерживаемым средством управления для всех рабочих процессов платформы vSphere. О последней версии vSphere Client 3.42 мы писали осенью прошлого года вот тут.

Теперь VMware в обновленной версии клиента исправила несколько ошибок, а также отключила поддержку старых версий VMware vSphere. Новый клиент работает, начиная с vSphere 6.5 и более поздними версиями. То есть, если у вас vSphere 6.0, то не обновляйте ваш клиент (тем более, что линка на загрузку прошлой версии уже нет), а используйте версию 3.42, которая реализует весь функционал.

Также надо помнить, что если вы используете vSphere 6.5, то у вас будет недоступен плагин к VMware vSphere Update Manager (VUM). Интересно, что в Changelog написано о том, что в клиенте есть некоторые New Features, но не написано, какие именно)

UPD. Новый клиент vSphere Client 4.0 предоставляет следующие новые возможности:

• Поддержка VMware vCenter 6.7, браузер просмотра файлов и папок стал работать заметно быстрее.
• Графический интерфейс ESX Agent Manager.
• Настройки MxN Convergence в разделе System Configuration
• Возможность импорта сертификатов и генерации запроса CSR.
• Функции Code Capture: кнопка записи может быть нажата между состояниями hidden и shown.
• Возможность удалить бандлы скриптов (Script Bundles) в механизме Autodeploy для vCenter 6.7.
• Возможность удалить Discovered hosts в механизме Autodeploy для vCenter 6.7.
• Экспорт данных о лицензиях в формате CSV для всех представлений, связанных с просмотром лицензий.
• Добавление и назначение лицензий в рамках одной операции.
• Настройка аутентификации на прокси-сервере для VC 6.5+ (раздел VC > Configure  > Settings > Authentication Proxy).

При обновлении клиента на версию vSphere Client 4.0 с 3.x вам нужно будет повторно подключить его к инфраструктуре vSphere и ввести учетные данные.

Скачать VMware vSphere Client 4.0 можно по этой ссылке.

В прошлом посте мы рассказывали о IOchain - цепочке прохождения пакетов через сетевой стек хоста VMware ESXi, а в этом остановимся на некоторых утилитах, работающих с этим стеком и помогающих решать различного рода сетевые проблемы.

Прежде всего, при решении проблем соединений на хосте ESXi нужно использовать следующие средства:

• Консольная утилита esxtop (представление network)
• ping / vmkping
• traceroute

Но если хочется углубиться дальше в сетевое взаимодействие на хосте, то тут могут оказаться полезными следующие утилиты:

• net-stats
• pktcap-uw
• nc
• iperf

1. Net-stats.

Чтобы вывести весь список флагов этой команды, используйте net-stats -h, а вот для вывода детальной информации о номерах портов и MAC-адресах всех интерфейсов используйте команду:

net-stats -l

С помощью net-stats можно делать огромное количество всяких вещей, например, проверить включены ли на интерфейсе vmnic функции NetQueue или Receive Side Scaling (RSS) с помощью команды:

net-stats -A -t vW

Далее нужно сопоставить вывод блока sys для нужного интерфейса и вывода команды:

vsish -e cat /world/<world id>/name

2. Pktcap-uw.

Эта утилита совместно с tcpdump-uw захватывать пакеты на различных уровнях. Если tcpdump-uw позволяет захватывать пакеты только с интерфейсов VMkernel, то pktcap-uw умеет захватывать фреймы на уровне виртуального порта, коммутатора vSwitch или аплинка.

В KB 2051814 подробно описано, как можно использовать утилиту pktcap-uw. На картинке ниже представлен синтаксис использования команды, в зависимости от того, на каком уровне мы хотим ее применить:

• Фильтрация пакетов для выбранного MAC-адреса:

pktcap-uw --mac xx:xx:xx:xx:xx:xx

• Фильтрация пакетов для выбранного IP-адреса:

pktcap-uw --ip x.x.x.x

• Автоматическое исполнение и завершение pktcap-uw с использованием параметра sleep:

pktcap-uw $sleep 120; pkill pktcap-uw

• Ограничить захват заданным числом пакетов:

pktcap-uw -c 100

• Перенаправить вывод в файл:

pktcap-uw -P -o /tmp/example.pcap

3. NC

NC - это олдскульная Linux-команда NetCat. Она позволяет проверить соединение по указанному порту, так как telnet недоступен на ESXi. Например, так можно проверить, что можно достучаться через интерфейс iSCSI по порту 3260 до системы хранения:

nc -z <destination IP> 3260

В KB 2020669 вы можете найти больше информации об этой команде.

4. Iperf

Эта утилита предназначена для контроля пропускной способности на интерфейсе. Она используется механизмом vSAN proactive network performance test, который доступен в интерфейсе vSAN. Поэтому при ее запуске вы получите сообщение "Operation not permitted". Чтобы она заработала, нужно создать ее копию:

cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

По умолчанию утилита работает на портах, которые запрещены фаерволом ESXi, поэтому во время работы с ней нужно его потушить (не забудьте потом его включить):

esxcli network firewall set --enabled false

Теперь можно использовать эту утилиту для замера производительности канала (флаг -s - это сервер, -c - клиент):

/usr/lib/vmware/vsan/bin/iperf3.copy -s -B 192.168.200.91

/usr/lib/vmware/vsan/bin/iperf3.copy -c 192.168.200.91

Результат будет похожим на это:

Больше об использовании утилиты iperf3 вы можете узнать вот тут.

Как вы знаете, в VMware vSphere 6.7 Update 1 средство обновления vSphere Update Manager (VUM) получило множество новых возможностей, в том числе функцию обновления микрокода (firmware) I/O-адаптеров серверов, входящих в состав кластера vSAN. Эта функциональность как раз перекочевала туда из интерфейса vSAN (называлось это раньше Configuration Assist).

VUM использует утилиту обновления драйверов от вендора оборудования (сервера). Таким образом, обновление драйвера I/O-устройства (HBA-адаптера) можно включить в двухступенчатый цикл обновления хоста и не заниматься этим отдельно, что уменьшает общее время обновления.

Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее. Для этого он анализирует Release Catalog, учитывая информацию из HCL (Hardware Compatibility List). При этом поддерживаются и кастомные ISO-образы от OEM-производителей (версия билда ESXi также распознается).

Когда вы зайдете в Host Updates в VUM, вы увидите вот такое сообщение:

Firmware engine needs to download hardware vendor’s firmware tool to vCenter.

Если вы нажмете "Download vendor firmware tool", то увидите, что для загрузки утилиты обновления микрокода можно использовать как дефолтный, так и свой репозиторий:

Как это известно по ситуации с драйверами Windows, установщик не найдет нужный драйвер, поэтому, скорее всего, придется указать свой путь к утилите обновления, например для контроллера Dell PERC путь может выглядеть как-то так:

http://downloads.dell.com/FOLDER03037799M/1/vmware-esx-perccli-1.05.08.zip

Обратите внимание, что по кнопке Browse можно указать свой файл, если у вас нет подключения к интернету:

Кстати, проверки состояния vSAN health checks интегрированы с рабочими процессами Update Manager, что позволяет приостановить процесс обновления хостов кластера в случае, если после обновление с одним из них пошло что-то не так. Также есть возможность загрузить на сервер vCenter файл HCL-манифеста в формате JSON, чтобы указать соответствия билдов ESXi и оборудования, если вы обновляетесь через VUM в офлайн-режиме.

Давно мы не писали о новостях сертификации VMware Certified Professionall (VCP), тем более, что с этого года несколько меняются принципы наименования и прохождения сертификации.

Для начала отметим, что по-прежнему для получения сертификации требуется прохождение курса (очно или онлайн) в одном из авторизованных центров (например - такого) и сдача двух экзаменов - VMware vSphere Foundations для соответствующей версии и специализированного экзамена для выбранного направления сертификации, например, VMware Certified Professional 6.5 – Data Center Virtualization.

С 16 января этого года VMware переходит от системы сертификаций по номеру версии продукта к системе с привязкой к году сертификации (то есть, если вы сдадите экзамен после 16 января, вы уже будете VCP 2019). Например:

• Было: VMware Certified Professional – Desktop and Mobility 7 (VCP7-DTM)
• Стало: VMware Certified Professional – Desktop and Mobility 2019 (VCP-DTM 2019)

Более подробно об этой системе для сертификаций VCP и VCAP написано здесь. Такая схема, во-первых, позволит работодателю или заказчику понять реальную актуальность сертификации (например, VCP6.5-DCV - полностью актуальная сертификация на данный момент, но сама платформа vSphere 6.5 вышла еще в 2016 году).

Второй момент - с 24 января будет доступен новый экзамен на базе VMware vSphere 6.7, что позволит получить актуальную сертификацию VCP 2019 для актуальной версии платформы.

Таким образом, вот так теперь выглядят планируемые сертификации VMware VCP для 2019 года:

Согласно политикам VMware, после выпуска новой версии экзамена старый объявляется устаревшим в течение 4 месяцев. Для тех, кто прошел сертификацию по прошлым версиям (не более двух версий назад), есть 3 варианта апгрейда:

• Сдать новый экзамен.
• Сдать дельта-экзамен (он поменьше) в рамах бридж-сертификации, если это допускает сертификация.
• Использовать другие специфические опции VMware в рамках специальных анонсов.

Вот так выглядит путь апгрейда для VCP на данный момент:

А вот так - список бридж-путей для ресертификации от прошлых версий:

Недавно компания VMware сделала доступной онлайн интересную утилиту - VMware Configuration Maximums Tool. Она позволяет быстро и просто найти максимальные параметры конфигураций для различных продуктов VMware:

На данный момент поддерживаются решения NSX Data Center for vSphere, vSphere (правда пока еще нет vSphere 6.7 Update 1), VMware NSX-T, vRealize Operations Manager и VMware Site Recovery Manager, но, скорее всего, этот список будет быстро пополняться.

Помимо продукта VMware и его версии, можно также выбрать и категории максимумов, которые хочется посмотреть (хосты ESXi, виртуальные машины и т.п.). Также полученные результаты можно экспортировать в PDF.

Если в верхней части страницы перейти на вкладку Compare Limits, то мы увидим функционал сравнения максимумов в различных версиях продуктов. Например, выберем слева VMware vSphere 6.7 и сравним с ней две предыдущих версии платформы - vSphere 6.5 Update 1 и vSphere 6.5:

Результаты будут приведены в таблице (обратите внимание, что их можно экспортировать в CSV):

В общем, полезная штука - пользуйтесь.

Недавно мы писали про то, как работает механизм регулирования полосы канала Network I/O Control (NIOC) в VMware vSphere, который позволяет приоритизировать различные типы трафика на одном сетевом адаптере, а сегодня взглянем на сам механизм прохождения трафика по уровням абстракции виртуального коммутатора изнутри.

Цепочка прохождения пакетов по сетевому стеку гипервизора ESXi через различные уровни называется Network IOChain. Это фреймворк, который позволяет на пути следования данных от виртуальной машины к физическому сетевому адаптеру производить различную модификацию данных и передачу их на следующий уровень.

IOChain обеспечивает связность виртуального коммутатора vSphere Standard Switch (VSS) или vSphere Distributed Switch (VDS) от групп портов на них к портам физических сетевым адаптеров (uplikns) в процессе передачи и обработки пакетов между этими сущностями. Для каждого из виртуальных коммутаторов есть 2 интерфейса IOChain (для входящего и исходящего трафика). Это дает большую гибкость по настройке политик каналов трафика Ingress и Egress.

Примерами таких политик служат поддержка сетей VLAN, механизма группировки NIC teaming и шейпинг трафика (traffic shaping). Работают эти политики на трех уровнях абстракции (в порядке следования от виртуальной машины):

• Группа портов виртуального коммутатора (port group).

На этом уровне работает фильтрация VLAN, а также политики безопасности, такие как Promiscuous mode, MAC address changes и Forged transmits. Пользователи также могут настроить политики шейпинга исходящего трафика (для VSS) или в обоих направлениях (только для VDS).

• Обычный или распределенный виртуальный коммутатор (VSS или VDS).

Основная задача этого уровня - направлять пакеты к нужному порту (аплинку), через которые они достигнут адреса назначения. Он оперирует MAC-адресами источника и назначения, а также определяет, отдавать ли трафик локально (в рамках одного или нескольких виртуальных коммутаторов на хосте), либо перенаправлять его к уровню аплинка хоста ESXi.

Кроме того, на этом уровне настраиваются правила NIC teaming по балансировке пакетов между аплинками, подключенными к данному коммутатору. Ну и на этом уровне можно также настраивать политики шейпинга и безопасности для всего виртуального коммутатора в целом.

• Порт (uplink).

Этот уровень отвечает за передачу трафика к драйверу сетевого адаптера. На этом уровне работают функции hardware offloading, облегчающие работу с обработкой пакетов за счет ресурсов сетевой карты. Доступные возможности hardware offloading зависят от конкретной модели карты и ее драйвера. Примерами таких возможностей являются TCP Segment Offload (TSO), Large Receive Offload (LRO) и Checksum Offload (CSO). Также здесь обеспечивается поддержка оверлейных протоколов VXLAN и Geneve, которые используются в решениях NSX-v и NSX-T соответственно (эта поддержка есть во многих современных сетевых картах).

Помимо этого на уровне аплинка работают механизмы буфферизации пакетов при всплесках нагрузки (ring buffers), после чего пакеты передаются на DMA-контроллер, чтобы быть обработанными процессором карты и перенаправлены уже в сеть передачи данных.

Для обычного виртуального коммутатора (VSS) схема прохождения трафика через уровни абстракции IOChain выглядит так:

Если же у вас распределенный виртуальный коммутатор VDS, то вы можете использовать механизм Network I/O Control (NIOC) для резервирования и приоритизации трафика внутри канала аплинков. Также VDS предоставляет множество дополнительных возможностей, таких как LBT (Load Balanced Teaming) и LACP (Link Aggregation Control Protocol).

В случае с VDS схема с IOChain выглядит следующим образом:

Обратите внимание, что на этой диаграмме есть дополнительный модуль DVfilter. Это API-фреймворк, который есть в VDS и требуется для работы решения NSX. Когда компоненты NSX устанавливаются в ядро ESXi, они взаимодействуют с трафиком именно через этот модуль.

С помощью команды summarize-dvfilter можно вывести все загруженные агенты DVfilter и фильтры. Вот так это выглядит без установленного решения NSX:

Если вы посмотрите информацию по компонентам NSX, когда он установлен, то увидите модули nxst-switch-security, nsxt-vsip и nsxt-vdrb.

Вообще, весь стек IOChain является модульным, что позволяет добавлять новую функциональность его компонентов на различных уровнях абстракции. Например, компоненты DVfilter разделяются на Fastpaths, Slowpaths и Filters:

• Fastpaths – фильтры трафика на уровне ядра ESXi.
• Slowpaths – интеграция со сторонними продуктами для сетевой инфраструктуры.
• Filters – размещение фильтров в слоты для каждого из подходящих по модели сетевых адаптеров vNIC.

В VMware vSphere 6.7 в стеке IOChain появилось несколько улучшений, таких как поддержка MAC learning и функции IGMP snooping через интерфейс VNI (Virtual Network Interface), которые могут быть использованы в будущем.

Ну и напомним, что текущая версия распределенного виртуального коммутатора VDS - это 6.6, об их обновлении мы писали вот тут.

Весной 2018 года Selectel запустил услугу резервного копирования для Облака на базе VMware посредством Veeam® Backup&Replication™ (далее VBR). К реализации проекта мы подошли основательно, спланировали и выполнили следующий перечень работ:

• Изучение документации и лучших практик по продуктам Veeam
• Разработку архитектуры VBR уровня сервис-провайдера
• Развертывание инфраструктуры VBR

Недавно мы писали о политиках хранилищ Storage Policy Based Management (SPBM) на базе тэгов, которые помогают использовать возможности платформы VMware vSphere для назначения виртуальным машинам хранилищ на томах VMFS/NFS с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Сегодня мы поговорим о политиках SPBM для виртуальных томов VVols на хранилищах, которые предоставляют различные возможности через интерфейс VASA (vSphere APIs for Storage Awareness). Механизм VASA реализуется производителем дисковой системы (storage provider) на программно-аппаратном уровне, при этом дисковый массив полностью отвечает за использование его возможностей, а со стороны vSphere возможно только управление ими средствами механизма SPBM.

Через интерфейс VASA Provider устройство хранения сообщает платформе vSphere, какие сервисы оно предоставляет, а через административный том на хранилище Protocol Endpoint (PE) происходит процессинг операций ESXi с массивом:

К таким возможностям в общем случае относятся:

• Шифрование
• Дедупликация данных на массиве
• Репликация данных внутри массива и на другие массивы
• Функции уровня обслуживания QoS (ограничения по IOPS и Latency)
• Выбор яруса хранения / типа дисков (регулирование уровня производительности)

Также возможна реализация в массиве и других сервисов, таких как защита с помощью снапшотов, использование различных размеров блока для разных приложений и т.п.

Самое приятное в использовании механизма SPBM для хранилищ на основе VVols в том, что вам не требуется заботиться о томах LUN, дисковых группах и настройке их параметров - массив сам распорядится размещением данных по ярусам (Tiers) и датасторам, а также обеспечением уровня их производительности (Service levels).

Например, вот так просто выглядят правила (Rules) для первичного размещения виртуальных машин на массиве EMC Unity при выборе уровня обслуживания и производительности для новой политики SPBM:

В массивах может быть также реализован QoS в зависимости от критичности приложения (Mission Critical приложения всегда первыми получат ресурсы ввода-вывода):

Некоторые хранилища, например, HPE Nimble, могут предоставлять сразу большое число сервисов, для каждого из которых можно настроить свои правила:

Хранилище может предоставлять не только правила размещения виртуальных машин и обеспечения их функционирования, но и сервисы репликации, как например у Pure Storage (они позволяют, в том числе, настроить репликацию на уровне отдельных VMDK дисков машин):

Также создание политик SPBM для томов VVols можно посмотреть на видео ниже:

А вот так применяются политики SPBM, включая сервисы репликации:

Когда вы обновляете виртуальную инфраструктуру VMware vSphere, нужно также подумать и об обновлении виртуального коммутатора (vSphere Distributed Switch, VDS), который, в зависимости от версии, предоставляет те или иные возможности.

Если вы хотите обновить VMware vSphere 5.5 на последнуюю версию VMware vSphere 6.7 Update 1, то, как вы уже знаете, прямого апгрейда нет. Вам нужно будет обновиться на одну из версий - vSphere 6.0 или 6.5 - и потом уже накатить апгрейд до версии 6.7.

В этом процессе есть нюанс - если вы обновитесь с 5.5 на 6.x, то вам надо будет обновить и Distributed Switch, до того, как будете проводить апгрейд на версию 6.7. В противном случае процесс обновления до версии 6.7 завершится неудачно.

Обновить распределенный коммутатор очень просто: в vSphere Client нужно зайти в Networking, выбрать там ваш VDS-коммутатор и на вкладке "Summary" кликнуть на ссылку, где написано "Upgrades available":

Чтобы запустить процесс обновления VDS, нужно в меню "Actions" выбрать пункт "Upgrade":

В процессе обновления вам предложат выбрать версию VDS, если кликнуть на иконку <i>, то можно узнать какие фичи предоставляют соответствующие версии:

Обратите внимание, что соответствие версий VDS версиям vSphere следующее:

• vSphere 6.0 = VDS 6.0
• vSphere 6.5 = VDS 6.5
• vSphere 6.7 = VDS 6.6 (да, вот так странно)

После обновления убедитесь, что виртуальный коммутатор имеет ту версию, которую вы выбрали:

И еще вам может оказаться полезной информация о потенциальных проблемах при обновлении на VDS 6.6, описанная в KB 52621.

Спустя всего 3 с небольшим месяца с момента анонса на конференции VMworld 2018 платформы для создания инфраструктуры виртуальных десктопов VMware Horizon 7.6, компания VMware выпустила обновление этого продукта - Horizon 7.7, включая обновленные клиенты Horizon Client 4.10.

Давайте посмотрим, что нового появилось в различных компонентах этого решения:

Улучшения совместимости и поддержка новых ОС

• Поддержка Windows Server 2019 для серверов виртуальных десктопов и RDSH.
• Поддержка последних версий VMware vSphere 6.7 U1 и VMware vSAN 6.7 Update 1.
• Поддержка облачного решения Horizon 7 on VMware Cloud on AWS (SDDC версии 1.5), включая все его новые возможности.
• Теперь апгрейды можно запускать через виртуальный модуль Horizon 7 Cloud Connector. Этот appliance используется для интеграции служб Horizon Cloud Service с компонентами Horizon 7 на площадках заказчиков и VMware Cloud on AWS.
• Пакет VMware Virtualization Pack for Skype for Business теперь может быть использован в окружении IPv6.
• Клиенты Horizon Clients теперь включают поддержку последних операционных систем, таких как macOS 10.14 (Mojave) и Android 9.1.

Улучшения консоли Management Console

Новая Horizon Console (на базе HTML5) получила несколько улучшений:

• Теперь можно добавлять пулы Manual и View Composer linked-clone, а также добавлять, отключать, изменять и удалять персистентные диски для связанных клонов.
• На вкладке Machines можно быстро понять, когда кто-либо, кроме назначенного пользователя, заходил в виртуальную машину. Теперь есть 2 колонки: Connected User и Assigned User (фича также доступна в Horizon Administrator).

• Старый Horizon Administrator в дэшборде System Health отображает детали о зарегистрированных модулях VMware Unified Access Gateway для версии 3.4 и более поздних:

• Имя узла Connection Server pod теперь есть в верхней панели, рядом с заголовком:

• Улучшение Help Desk Tool - администраторы теперь могут завершить процесс приложения для выбранного пользователя. База данных событий записывает это действие, включая такие детали, как дата и время, имя десктопа и название приложения, название пула и имя администратора.

Улучшения масштабируемости

• Можно использовать один экземпляр vCenter Server для нескольких POD в архитектуре CPA (Cloud Pod Architecture).
• Максимальное число серверов одной фермы RDSH было увеличено с 200 до 500.
• Была введена поддержка vMotion для пулов linked-clone и automated, которые содержат также и полные виртуальные машины.
• Поддержка vMotion была также добавлена для полных клонов с поддержкой vGPU, мгновенных клонов и связанных клонов.

Улучшения безопасности и надежности

• Новая возможность аудита буфера обмена позволяет агентам Horizon Agent записывать информацию об активностях операций copy и paste между клиентом и агентом в журнал событий на машине агента.
• Можно добавить устройство Virtual Trusted Platform Module (vTPM) к пулу десктопов instant-clone и удалить vTPM уже после операции по созданию образа.
• Протокол TLS 1.0 теперь отключен по умолчанию на всех клиентах.

Улучшения User Experience

• Улучшения протокола Blast Extreme:
  • Теперь можно использовать протокол Blast Extreme для доступа к физическим компьютерам и рабочим станциям.
  • Для Windows-клиентов протокол кодирования видео Blast Extreme HEVC (H.265) позволяет ужимать почти в два раза эффективнее чем раньше (при том же качестве), либо улучшать качество на той же самой полосе, как и H.264. Также добавлена поддержка режима 8K. Это требует окружения NVIDIA GRID с аппаратными кодировщиками NVIDIA и клиентов, железо которых поддерживает декодирование HEVC.
    
• Улучшения Windows-клиентов:
  • Если включена возможность client-drive redirection, пользователи могут перетаскивать файлы и папки между клиентской системой и удаленными десктопами или опубликованными приложениями. Например, можно перетащить несколько графических файлов в опубликованное приложение (например, закинуть аттач в почтовый клиент).
  • Новая возможность VMware Virtual Print позволяет пользователю печатать на любом Windows-компьютере (она делает то же самое, что и ThinPrint ранее). Но, помимо этого, VMware Virtual Print поддерживает перенаправление принтеров клиента, а также location-based printing. Настройки сохраняются на уровне пользователей.
• Улучшение опубликованных приложений и десктопов RDSH:
  • Режим multi-session mode, который позволяет администратору задать правило - можно ли пользователю открывать несколько сессий к одному приложению с различных устройств. Требует Horizon Client 4.10.
  • На Windows-клиентах пользователю можно назначить приложение RDSH для отображения на одном мониторе или на наборе из нескольких экранов.
  • Новая возможность hybrid logon может быть использована с функцией доступа для неавторизованных пользователей. Она позволяет неаутентифицированным пользователям, но с доступом к домену, получить доступ к сетевым ресурсам (файловые шары, принтеры), без ввода данных учетной записи домена. Требует Horizon Client 4.10.

Улучшения работы публичного облака VMware Cloud on AWS (SDDC версии 1.5)

• Минимально требуемый размер кластера vSphere был уменьшен до 3 узлов. Также поддерживаются "растянутые" кластеры (stretched clusters).
• Поддержка технологий VMware NSX-T network virtualization и VMware vSAN datastore encryption.
• Поддержка технологий Horizon 7 издания Enterprise Edition: VMware User Environment Manager, VMware App Volumes и техники VMware Instant Clone.

Улучшения и новые возможности VMware Horizon 7 for Linux

• Десктопы Linux теперь поддерживаются в инфраструктуре Horizon 7 on VMware Cloud on AWS.
• Режим Single sign-on (SSO) теперь поддерживается для десктопов SLED/SLES 12.x.
• Аудиовход теперь поддерживается для десктопов SLED/SLES.
• Плавающий пул десктопов Instant clone теперь доступен при использовании SLED/SLES .
• Функция session collaboration доступна при использовании Linux-десктопа. Теперь можно приглашать других пользователей присоединиться к удаленной сессии.
• Десктопы Instant clone на базе Linux теперь позволяют офлайновое присоединение к домену Active Directory через Samba.

Более подробная информация о VMware Horizon 7.7 приведена по этой ссылке. Также здесь можно почитать документацию о VMware Horizon Clients, а вот тут написано про новые возможности Unified Access Gateway 3.4.

Компоненты VMware Horizon 7.7 доступны для загрузки уже сейчас по этой ссылке.

Недавно компания Gartner выпустила Magic Quadrant for Hyperconverged Infrastructure (HCI) за 2018 год, посвященный средствам создания гиперконвергентной инфраструктуры. Это такая среда, которая позволяет объединить вычислительные ресурсы, системы хранения и сети с помощью технологий виртуализации и собрать все компоненты в единую интегрированную сущность, которая управляется из одной точки.

Напомним, что об этом квадранте мы уже писали в начале года, и с тех пор кое-что изменилось:

Вот как было в январе этого года:

Главным лидером рейтинга, как и прежде, сейчас признана компания Nutainx - производитель продуктов для создания гиперконвергентной среды. Сейчас Nutanix поставляет как чисто программные решения (в виде виртуальных модулей), так и программно-аппаратные комплексы (партнерские решения Lenovo, Dell EMC, Fujitsu и IBM). Помимо этого, Nutanix в рамках раннего доступа запустила и облачный сервис для своих HCI-решений.

Несмотря на то, что VMware - это производитель только программных решений, она попала в сегмент лидеров вполне заслуженно. У VMware в последние годы было выпущено очень много того, что относится к HCI - например, сейчас компания поддерживает более 500 моделей серверов в рамках программы ReadyNode для построения кластеров vSAN.

Также VMware поддерживает инициативу VMware Cloud Foundation (VCF), о которой мы много писали в последнее время. Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить.

Ну и, конечно же, в последнее время VMware делает очень много усилий по продвижению гибридной среды VMware Cloud on AWS, которая будет доступна не только из облака, но и в частной инфраструктуре предприятий (Amazon Outposts).

Родительская компания VMware - Dell EMC - в этом квадранте занимает высокое место благодаря решениям VxRail и VxRack, в состав которых, кстати, входит продукт для создания кластеров отказоустойчивых хранилищ vSAN.

Обратите внимание, что существенный прогресс наблюдается у Cisco - из сегмента челенджеров она переместилась в лидеры. Прежде всего, это случилось благодаря доработке платформы Cisco HyperFlex, котора интегрирует в себе архитектуру Cisco Unified Computing System (UCS), сочетающую в себе продукты Network Fabric, управляющую облачную консоль Intersight, сторонний гипервизор (например, ESXi), а также платформу для управления хранилищами и данными HX Data Platform (разработанную компанией Springpath, которую Cisco купила в сентябре 2017 года).

О магических квадрантах Gartner

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

В начале года мы рассказывали о книге Upgrading to VMware vSphere 6.5, которая описывала процедуры апгрейда платформы виртуализации на версию 6.5. С тех пор были выпущены обновления vSphere 6.7 и 6.7 Update 1, поэтому документ потерял актуальность.

В связи с этим VMware выпустила обновленную книгу Дэвида Стамена (David Stamen) Upgrading to VMware vSphere 6.7, которая стала доступна для скачивания на днях:

В обновленную версию также включены все нововведения последних версий продуктов Site Recovery Manager и Horizon, которые работают в инфраструктуре vSphere. С точки зрения основной платформы, рассматриваются сценарии апгрейда с vSphere 6.0 и 6.5.

В книге процесс обновления разбит на три фазы:

• Фаза 1: Pre-upgrade – обозначает фронт работ и требований, которые должны быть выполнены перед началом процедуры апгрейда.
• Фаза 2: Upgrade – описание шагов процесса обновления и иллюстрация их исполнения.
• Фаза 3: Post-Upgrade – валидация результата в соответствии с изначально поставленными целями.

Скачать книгу Upgrading to VMware vSphere 6.7 можно по этой ссылке.